CPython's macOS framework build embeds Python.app under
Python.framework/Versions/<X.Y>/Resources/Python.app. The launcher's
Mach-O carries the configure-time --enable-framework path as a
hardcoded `LC_LOAD_DYLIB` load command:

    /Users/runner/work/python-build/python-build/darwin/install/
        macOS/macosx/python-X.Y.Z/Python.framework/Versions/X.Y/Python

DYLD can't resolve that path on any machine other than the runner that
produced the build. The CPython source tree's `make install` doesn't
post-process this — Beeware's Python-Apple-support patches install_names
to @rpath, but we don't run that step.

The consequence in downstream consumers: when the xcframework lands
inside a host .app's Contents/Frameworks/Python.framework/, macOS
LaunchServices' nested-bundle scan finds Python.app and tries to launch
it, producing a "Python quit unexpectedly" crash report dialog every
time a `flet build` artifact starts. flet-dev/serious-python is currently
working around this by `find ... -name Python.app | xargs rm -rf` after
extracting the tarball; that should live here, in the build pipeline.

For the embedded-interpreter use case (which is all flet-dev/serious-
python builds for) the launcher has no role: libdart_bridge dlopens
Python.framework's main binary directly, the host application supplies
the NSApplication context, and sys.executable resolves to the host app
binary — Python.app would never be exercised.

Iff a downstream consumer needs a true standalone macOS Python launcher
they can take it directly from Python-Apple-support; we'd reintroduce a
fix-up step then. For now: drop it.

Proper upstream fix (Python-Apple-support relocating LC_LOAD_DYLIB to
@rpath in Python.app) tracked as a follow-up.